共用方式為


針對 Windows Server 軟體定義的網路堆疊進行疑難解答

本指南會檢查常見的軟體定義網路 (SDN) 錯誤和失敗案例,並概述使用可用診斷工具的疑難排解工作流程。 如需關於 SDN 的詳細資訊,請參閱軟體定義網路

適用於: Windows Server 2022、Windows Server 2019、Windows Server 2016、Azure Stack HCI、版本 21H2 和 20H2

錯誤類型

下列清單代表 Windows Server 2012 R2 中 Hyper-V 網路虛擬化 (HNVv1) 最常從市場內生產部署看到的問題類別,且在許多方面與 Windows Server 2016 HNVv2 中與新的軟體定義網路 (SDN) 堆疊中遇到的問題類型相同。

大部分的錯誤都可分類成一組小類別:

  • 無效或不支持的組態

    用戶不正確地叫用 NorthBound API 或無效的原則。

  • 原則應用程式中的錯誤

    來自網路控制站的原則未傳遞到 Hyper-V 主機、延遲或不是所有 Hyper-V 主機上的最新狀態(例如,即時移轉之後)。

  • 設定漂移或軟體錯誤

    導致封包捨棄的數據路徑問題。

  • 與 NIC 硬體/驅動程式或底層網路網狀架構相關的外部錯誤

    工作卸除不當(例如 VMQ)或網路網狀架構設定錯誤(例如 MTU)

    此疑難排解指南會逐一檢查這些錯誤類別,並建議可用來識別並修正錯誤的最佳做法和診斷工具。

診斷工具

在討論上述每個錯誤類型的疑難排解工作流程之前,讓我們來檢查可用的診斷工具。

若要使用網路控制站(控制路徑)診斷工具,您必須先安裝 RSAT-NetworkController 此功能並匯入 NetworkControllerDiagnostics 模組:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

若要使用 HNV 診斷 (資料路徑) 診斷工具,您必須匯入 HNVDiagnostics 模組:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

網路控制卡診斷

這些 Cmdlet 記載於網路控制站診斷 Cmdlet 中的 TechNet 上。 其有助於在網路控制卡節點之間與在 Hyper-V 主機上執行的 NC 主機代理程式之間,找出控制路徑中網路原則一致性的問題。

Debug-ServiceFabricNodeStatusGet-NetworkControllerReplica Cmdlet 必須從其中一個網路控制站節點虛擬機執行。 您可從任何主機執行所有其他 NC 診斷 Cmdlet,該主機可連線到網路控制卡,且位於網路控制卡管理安全性群組 (Kerberos) 中,或可存取 X.509 憑證來管理網路控制卡。

Hyper-V 主機診斷

這些 Cmdlet 記載於 Hyper-V 網路虛擬化 (HNV) 診斷 Cmdlet 中的 TechNet 上。 其可協助找出租用戶虛擬機器 (東/西) 與透過 SLB VIP (北/南) 輸入流量之間的資料路徑問題。

Debug-VirtualMachineQueueOperationGet-CustomerRouteGet-PACAMapping、、Get-VMNetworkAdapterPortIdGet-ProviderAddressGet-VMSwitchExternalPortIdTest-EncapOverheadSettings 都是可從任何 Hyper-V 主機執行的本機測試。 其他 Cmdlet 會透過網路控制卡叫用資料路徑測試,因此需要存取網路控制卡,如上所述。

GitHub

Microsoft/SDN GitHub 存放庫有許多以這些附隨 Cmdlet 為基礎的範例指令碼和工作流程。 特別是,您可以在診斷資料夾中找到診斷指令碼。 您可以提交提取要求,協助我們參與這些指令碼。

針對工作流程和指南進行疑難解答

[Hoster]驗證系統健康情況

在數個網路控制卡資源中,有一個名為 Configuration State 的內嵌資源。 設定狀態提供系統健康情況的相關資訊,包括網路控制卡組態與 Hyper-V 主機上實際 (執行中) 狀態之間的一致性。

若要檢查組態狀態,請從任何連線到網路控制卡的 Hyper-V 主機執行下列命令。

注意

參數的值 NetworkController 應該是 FQDN 或 IP 位址,根據為網路控制站建立之 X.509 >憑證的主體名稱。

Credential只有在網路控制站使用 Kerberos 驗證時,才需要指定 參數(通常是在 VMM 部署中)。 認證必須適用於網路控制卡管理安全性群組中的使用者。

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

組態狀態訊息範例如下所示:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

注意

系統發生錯誤,其中 SLB Mux 傳輸 VM NIC 的網路介面資源處於失敗狀態,並出現錯誤:「虛擬交換器 - 主機未連線至控制器」。 如果 VM NIC 資源中的 IP 設定設為傳輸邏輯網路 IP 集區中的 IP 位址,則可以安全地忽略此錯誤。

系統發生第二個錯誤,其中閘道 HNV 提供者 VM NIC 的網路介面資源處於失敗狀態,並出現錯誤:「虛擬交換器 - PortBlocked」。 如果 VM NIC 資源中的 IP 設定設為 null (依設計),也可以安全地忽略此錯誤。

下表顯示根據所觀察到組態狀態所要採取的錯誤碼、訊息和後續動作清單。

代碼 訊息 動作
未知 未知錯誤
HostUnreachable 無法連線主機電腦 檢查網路控制卡與主機之間的管理網路連線
PAIpAddressExhausted PA IP 位址用盡 增加 HNV 提供者邏輯子網路的 IP 集區大小
PAMacAddressExhausted PA Mac 位址用盡 增加 Mac 集區範圍
PAAddressConfigurationFailure 無法將 PA 位址管道傳送至主機 檢查網路控制卡與主機之間的管理網路連線。
CertificateNotTrusted 憑證未受信任 修正用來與主機通訊的憑證。
CertificateNotAuthorized 憑證未獲授權 修正用來與主機通訊的憑證。
PolicyConfigurationFailureOnVfp 設定 VFP 原則失敗 這是執行階段失敗。 沒有明確的因應措施。 收集記錄檔。
PolicyConfigurationFailure 由於 NetworkController 中的通訊失敗或其他錯誤,因此推送原則至主機時失敗。 沒有明確的動作。 這是因為網路控制卡模組中的目標狀態處理失敗。 收集記錄檔。
HostNotConnectedToController 主機尚未連線到網路控制卡 通訊埠設定檔未在主機上套用,或無法從網路控制卡連線到主機。 驗證 HostID 登錄機碼是否符合伺服器資源的執行個體識別碼
MultipleVfpEnabledSwitches 主機上有多個已啟用 VFp 的交換器 刪除其中一個交換器,因為網路控制卡主機代理程式僅支援已啟用 VFP 延伸模組的一個 vSwitch
PolicyConfigurationFailure 由於憑證錯誤或連線錯誤,因此無法推送 VmNic 的 VNet 原則 檢查是否已部署適當的憑證 (憑證主體名稱必須符合主機的 FQDN)。 同時確認主機與網路控制卡的連線
PolicyConfigurationFailure 由於憑證錯誤或連線錯誤,因此無法推送 VmNic 的 vSwitch 原則 檢查是否已部署適當的憑證 (憑證主體名稱必須符合主機的 FQDN)。 同時確認主機與網路控制卡的連線
PolicyConfigurationFailure 由於憑證錯誤或連線錯誤,因此無法推送 VmNic 的防火牆原則 檢查是否已部署適當的憑證 (憑證主體名稱必須符合主機的 FQDN)。 同時確認主機與網路控制卡的連線
DistributedRouterConfigurationFailure 無法在主機 vNic 上設定分散式路由器設定 TCPIP 堆疊錯誤。 可能需要在回報此錯誤的伺服器上清除 PA 和 DR 主機 vNIC
DhcpAddressAllocationFailure VMNic 的 DHCP 位址配置失敗 檢查是否已在 NIC 資源上設定靜態 IP 位址屬性
CertificateNotTrusted
CertificateNotAuthorized
由於網路或憑證錯誤,因此無法連線到 Mux 檢查錯誤訊息碼中提供的數值碼:這會對應至 winsock 錯誤碼。 憑證錯誤是細微的 (例如,憑證無法驗證、憑證未獲授權等)
HostUnreachable MUX 狀況不良 (常見案例為 BGPRouter 已中斷連線) RRAS (BGP 虛擬機器) 或機架頂端 (ToR) 交換器上的 BGP 對等互連無法連線或無法成功對等互連。 檢查軟體負載平衡器多工器資源和 BGP 對等互連 (ToR 或 RRAS 虛擬機器) 上的 BGP 設定
HostNotConnectedToController SLB 主機代理程式未連線 檢查 SLB 主機代理程式服務是否正在執行;如需原因,請參閱 SLB 主機代理程式記錄 (自動執行),如果 SLBM (NC) 拒絕主機代理程式執行狀態所提供的憑證,則會顯示細微資訊
PortBlocked 由於 VNET /ACL 原則不足,因此已封鎖 VFP 連接埠 檢查是否有任何其他錯誤,可能會導致原則未設定。
超載 Loadbalancer MUX 已多載 MUX 的效能問題
RoutePublicationFailure Loadbalancer MUX 未連線到 BGP 路由器 檢查 MUX 是否與 BGP 路由器連線,以及 BGP 對等互連是否已正確設定
VirtualServerUnreachable Loadbalancer MUX 未連線到 SLB 管理員 檢查 SLBM 與 MUX 之間的連線
QosConfigurationFailure 無法設定 QOS 原則 如果已使用 QOS 保留區,請查看是否有足夠的頻寬可供所有 VM 使用

檢查網路控制卡與 Hyper-V 主機 (NC 主機代理程式服務) 之間的網路連線

netstat執行下列命令,以驗證 NC 主機代理程式與網路控制站節點之間有三ESTABLISHED個連線,以及 Hyper-V 主機上的一個LISTENING套接字。

  • 在 Hyper-V 主機上 LISTENING 連接埠 TCP:6640 (NC 主機代理程式服務)
  • 從連接埠 6640 上的 Hyper-V 主機 IP 到暫時連接埠上 NC 節點 IP 的兩個已建立連線 (> 32000)
  • 一個從暫時連接埠上的 Hyper-V 主機 IP 到連接埠 6640 上的網路控制卡 REST IP 的已建立連線

注意

如果沒有任何租用戶虛擬機器部署在該特定主機上,則 Hyper-V 主機上可能只有兩個已建立的連線。

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

檢查主機代理程式服務

網路控制卡會與 Hyper-V 主機上的兩個主機代理程式服務進行通訊:SLB 主機代理程式和 NC 主機代理程式。 可能其中一個服務或可能兩個服務都未執行。 檢查其狀態,並在未執行時重新啟動。

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

檢查網路控制卡的健康情況

如果沒有三 ESTABLISHED 個連線,或網路控制站似乎沒有回應,請檢查是否使用下列 Cmdlet 來查看所有節點和服務模組都已啟動並執行。

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

網路控制卡服務模組如下:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

檢查 是否 ReplicaStatus 為 ,且 Ready HealthStateOk

在生產部署中,使用多節點網路控制站,您也可以檢查每個服務的主要節點及其個別複本狀態。

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

檢查每個服務的 [複本狀態] 是否都已 [就緒]。

檢查網路控制站與每個 Hyper-V 主機之間的對應 HostID 和憑證

在 Hyper-V 主機上,執行下列 Cmdlet 來檢查 HostID 是否對應至網路控制站上伺服器資源的實例識別碼

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

補救

如果使用 SDNExpress 腳本或手動部署,請更新登錄中的 HostId 機碼,以符合伺服器資源的實例識別碼。 如果使用 VMM,請重新啟動 Hyper-V 主機 (實體伺服器) 上的網路控制卡主機代理程式,請從 VMM 刪除 Hyper-V 伺服器,並移除 HostId 登錄機碼。 然後,再次透過 VMM 新增伺服器。

檢查 Hyper-V 主機 (主機名稱為憑證的主體名稱) 所使用的 X.509 憑證指紋,以取得 Hyper-V 主機 (NC 主機代理程式服務) 與網路控制卡節點之間的 (SouthBound) 通訊憑證主體名稱。 也請檢查網路控制站的 REST 憑證的主體名稱為 CN=<FQDN or IP>

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

您也可以檢查每個憑證的下列參數,以確定主體名稱是預期的專案(主機名或 NC REST FQDN 或 IP),憑證尚未過期,而且憑證鏈結中的所有證書頒發機構單位都包含在受信任的根授權單位中。

  • 主體名稱
  • 到期日
  • 受根授權單位信任

如果 Hyper-V 主機上有多個憑證具有相同的主體名稱,網路控制站主機代理程式會隨機選擇一個來呈現給網路控制站。 這可能與網路控制站已知的伺服器資源指紋不符。 在此情況下,請刪除 Hyper-V 主機上具有相同主體名稱的其中一個憑證,然後重新啟動網路控制卡主機代理程式服務。 如果仍然無法建立連線,請刪除 Hyper-V 主機上具有相同主體名稱的其他憑證,並刪除 VMM 中對應的伺服器資源。 然後,在 VMM 中重新建立伺服器資源,這會產生新的 X.509 憑證,並將其安裝在 Hyper-V 主機上。

檢查 SLB 組態狀態

SLB 組態狀態可以判斷為 Cmdlet 輸出的 Debug-NetworkController 一部分。 此 Cmdlet 也會輸出 JSON 檔案中目前的網路控制卡資源集、每個 Hyper-V 主機 (伺服器) 的所有 IP 組態,以及主機代理程式資料庫資料表的區域網路原則。

預設會收集更多追蹤。 若要不收集追蹤,請新增 -IncludeTraces:$false 參數。

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

注意

預設輸出位置會是 <working_directory>\NCDiagnostics\ 目錄。 您可以使用 -OutputDirectory 參數來變更預設輸出目錄。

您可以在此目錄中的 diagnostics-slbstateResults.Json 檔案中找到 SLB 組態狀態資訊。

此 JSON 檔案可以細分成下列各節:

  • 網狀架構
    • SlbmVips - 本節列出 SLB 管理員 VIP 位址的 IP 位址,網路控制卡會使用此位址來協調 SLB Muxes 與 SLB 主機代理程式之間的設定和健康情況。
    • MuxState - 本節會針對每個部署的 SLB Mux 列出一個值,並提供 MUX 的狀態
    • 路由器組態 - 本節將列出上游路由器 (BGP 對等) 的自發系統編號 (ASN)、傳輸 IP 位址和識別碼。 其也會列出 SLB Muxes ASN 和傳輸 IP。
    • 連線主機資訊 - 本節將列出所有可用來執行負載平衡工作負載 Hyper-V 主機的管理 IP 位址。
    • VIP 範圍 - 本節將列出公用和私人 VIP IP 集區範圍。 將會包含 SLBM VIP 做為其中一個範圍的已配置 IP。
    • Mux 路由 - 本節會針對每個部署的 SLB Mux 列出一個值,其中包含該特定 Mux 的所有路由公告。
  • 租用戶
    • VipConsolidatedState - 本節會列出每個租用戶 VIP 的連線狀態,包括公告的路由首碼、Hyper-V 主機和 DIP 端點。

注意

您可以使用 Microsoft SDN GitHub 存放庫中提供的 DumpSlbRestState 指令碼,直接確定 SLB 狀態。

閘道驗證

從網路控制站:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

從閘道 VM:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

從機架頂端 (ToR) 交換器:

sh ip bgp summary (for 3rd party BGP Routers)

Windows BGP 路由器:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

除了這些之外,從目前為止我們所看到的問題 (特別是在 SDNExpress 型部署上),在 GW VM 上未設定租用戶區間最常見的原因,似乎是相較於其他人嘗試指派至 TenantConfig.psd1 中網路連線 (S2S 通道) 的 GW 容量,FabricConfig.psd1 中的 GW 容量較少。 藉由比較下列 Cmdlet 的輸出,即可輕鬆檢查此問題:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[主機服務提供者] 驗證資料平面

部署網路控制卡之後,即已建立租用戶虛擬網路和子網路,且 VM 已連結至虛擬子網路,主機服務提供者可以執行額外的網狀架構層級測試,以檢查租用戶連線。

檢查 HNV 提供者邏輯網路連線能力

在 Hyper-V 主機上執行的第一個客體 VM 已連線到租用戶虛擬網路之後,網路控制卡會將兩個 HNV 提供者 IP 位址 (PA IP 位址) 指派給 Hyper-V 主機。 這些 IP 會來自 HNV 提供者邏輯網路的 IP 集區,並且由網路控制站管理。 若要瞭解這兩個 HNV IP 位址是什麼:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

系統會將這些 HNV 提供者 IP 位址 (PA IP) 指派給在個別 TCPIP 網路區間中建立的乙太網路卡,並且會使用 VLANX 的介面卡名稱,其中 X 是指派給 HNV 提供者 (傳輸) 邏輯網路的 VLAN。

使用 HNV 提供者邏輯網路的兩部 Hyper-V 主機之間的連線,可透過具有額外區間 (-c Y) 參數的 Ping 來完成,其中 Y 是建立 PAhostVNIC 位置的 TCPIP 網路區間。 此區間可藉由執行下列方式進行判斷:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

注意

PA 主機 vNIC 配接器不會用於資料路徑,因此沒有指派給「vEthernet (PAhostVNic) 配接器」的 IP。

例如,假設 Hyper-V 主機 1 和 2 具有 HNV 提供者 (PA) IP 位址:

Hyper-V 主機 PA IP 位址 1 PA IP 位址 2
主機 1 10.10.182.64 10.10.182.65
主機 2 10.10.182.66 10.10.182.67

我們可以使用下列命令,在兩者之間進行 Ping,以檢查 HNV 提供者邏輯網路連線。

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

補救

如果 HNV 提供者 Ping 無法運作,請檢查您的實體網路連線,包括 VLAN 設定。 每個 Hyper-V 主機上的實體 NIC 都應該處於主幹模式,且不指派特定的 VLAN。 管理主機 vNIC 應該隔離至管理邏輯網路的 VLAN。

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

檢查 HNV 提供者邏輯網路上的 MTU 和巨型框架支援

HNV 提供者邏輯網路的另一個常見問題是,實體網路埠和/或乙太網路卡未設定足夠的 MTU,以處理 VXLAN (或 NVGRE) 封裝的額外負荷。

注意

某些乙太網路卡和驅動程序支援新的 *EncapOverhead 關鍵詞,網路控制卡主機代理程式會自動將它設定為160的值。 此值接著會新增至 *JumboPacket 關鍵字的值,其總和會做為公告的 MTU 使用。

例如, *EncapOverhead = 160 和 *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

若要測試 HNV 提供者邏輯網路是否支援較大的 MTU 大小端對端,請使用 Test-LogicalNetworkSupportsJumboPacket Cmdlet:

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

補救

  • 將實體交換器連接埠上的 MTU 大小調整為至少 1674B (包括 14B 乙太網路標頭和結尾)
  • 如果您的 NIC 卡不支援 EncapOverhead 關鍵詞,請將 JumboPacket 關鍵詞調整為至少 1674B

檢查租使用者 VM NIC 連線能力

指派給客體 VM 的每個 VM NIC 在私人客戶位址 (CA) 與 HNV 提供者位址 (CA) 空間之間都有 CA-PA 對應。 這些對應會保留在每個 Hyper-V 主機上的 OVSDB 伺服器資料表中,且可以透過執行下列 Cmdlet 來找到。

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

注意

如果您預期的 CA-PA 對應不是指定租使用者 VM 的輸出,請使用 Cmdlet 檢查網路控制站 Get-NetworkControllerNetworkInterface 上的 VM NIC 和 IP 組態資源。 此外,請檢查 NC 主機代理程式與網路控制卡節點之間的已建立連線。

透過這項資訊,現在可以使用 Cmdlet 從網路控制站 Test-VirtualNetworkConnection 起始租使用者 VM Ping。

特定疑難解答案例

下列各節提供針對特定案例進行疑難排解的指引。

兩部租用戶虛擬機器之間沒有網路連線

  1. [租用戶] 確定租用戶虛擬機器中的 Windows 防火牆不會封鎖流量。
  2. [租使用者]執行 ipconfig,檢查IP位址是否已指派給租使用者虛擬機。
  3. [Hoster]從 Hyper-V 主機執行 Test-VirtualNetworkConnection ,以驗證有問題的兩部租使用者虛擬機之間的連線。

注意

VSID 是指虛擬子網路識別碼。 在 VXLAN 的情況下,這是 VXLAN 網路識別碼 (VNI)。 您可以執行 Get-PACAMapping Cmdlet 來尋找此值。

範例

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

在「Green Web VM 1」之間建立 CA-ping,在主機「sa18n30-2.sa18.nttest.microsoft.com」上 SenderCA IP 為 192.168.1.4,Mgmt IP 為 10.127.132.153 至 ListenerCA IP 為 192.168.1.5,兩者皆連接到虛擬子網路 (VSID) 4114。

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[租用戶] 檢查虛擬子網路上沒有指定分散式防火牆原則,或封鎖流量的 VM 網路介面。

在 sa18.nttest.microsoft.com 網域的 sa18n30nc 示範環境中查詢網路控制卡 REST API。

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

查看參考此 ACL 的IP組態和虛擬子網

  1. [主機服務提供者] 在裝載有問題的兩部租用戶虛擬機器的 Hyper-V 主機上執行 Get-ProviderAddress,然後從 Hyper-V 主機執行 Test-LogicalNetworkConnectionping -c <compartment>,以驗證 HNV 提供者邏輯網路上的連線
  2. [主機服務提供者] 確定 Hyper-V 主機上的 MTU 設定正確無誤,以及 Hyper-V 主機之間的任何第 2 層切換裝置。 在所有有問題的 Hyper-V 主機上執行 Test-EncapOverheadValue。 此外,檢查之間的所有第 2 層交換器是否將 MTU 設定為至少 1674 個位元組,以考慮 160 個位元組的最大額外負荷。
  3. [主機服務提供者] 如果 PA IP 位址不存在且/或 CA 連線中斷,請檢查以確定已收到網路原則。 執行 Get-PACAMapping 以查看建立重疊虛擬網路所需的封裝規則和 CA-PA 對應是否正確建立。
  4. [主機服務提供者] 檢查網路控制卡主機代理程式是否已連線到網路控制卡。 若要這麼做,請執行 netstat -anp tcp |findstr 6640
  5. [主機服務提供者] 檢查 HKLM/ 中的主機識別碼與裝載租用戶虛擬機器的伺服器資源執行個體識別碼是否相符。
  6. [主機服務提供者] 檢查通訊埠設定檔識別碼與租用戶虛擬機器的 VM 網路介面執行個體識別碼是否相符。

記錄、追蹤和進階診斷

下列各節提供進階診斷、記錄和追蹤的相關資訊。

網路控制卡集中式記錄

網路控制卡可以自動收集偵錯工具記錄,並將其儲存在集中式位置。 當您第一次或稍後部署網路控制卡時,可以啟用記錄收集。 會從網路控制卡收集記錄,以及網路控制卡所管理的網路元素:主機電腦、軟體負載平衡器 (SLB) 和閘道機器。

這些記錄包括網路控制卡叢集、網路控制卡應用程式、閘道記錄、SLB、虛擬網路和分散式防火牆的偵錯記錄。 每當您將新的主機/SLB/閘道新增至網路控制卡時,就會在這些機器上啟動記錄。 同樣地,當主機/SLB/閘道從網路控制卡移除時,這些機器上的記錄就會停止。

啟用記錄

當您使用 Install-NetworkControllerCluster Cmdlet 安裝網路控制站叢集時,會自動啟用記錄。 根據預設,會在 %systemdrive%\SDNDiagnostics 的網路控制卡節點上本機收集記錄。 建議您將此位置變更為遠端檔案共用(非本機)。

網路控制卡叢集記錄會儲存在 %programData%\Windows Fabric\log\Traces。 您可以使用 參數指定記錄收集的集中式位置, DiagnosticLogLocation 並建議這也是遠端檔案共用。

如果您想要限制此位置的存取,您可以使用 參數來提供存取認證 LogLocationCredential 。 如果您提供認證來存取記錄位置,則也應該提供 CredentialEncryptionCertificate 參數,用來加密儲存在網路控制站節點上本機的認證。

使用預設設定時,建議您在中央位置至少有 75 GB 的可用空間,以及在本機節點上有 25 GB (如果未使用中央位置) 的可用空間,以用於三個節點的網路控制卡叢集。

變更記錄設定

您可以隨時使用 Set-NetworkControllerDiagnostic Cmdlet 來變更記錄設定。 您可以變更下列設定:

  • 集中式記錄位置。

    您可以使用 DiagnosticLogLocation 參數,變更位置以儲存所有記錄。

  • 用來存取記錄位置的認證。

    您可以使用 LogLocationCredential 參數,變更認證以存取記錄位置。

  • 移至本機記錄。

    如果您提供集中式位置來儲存記錄,則可以使用 UseLocalLogLocation 參數回到網路控制卡節點上的本機記錄 (由於磁碟空間需求較大,因此不建議這麼做)。

  • 記錄範圍。

    根據預設,會收集所有記錄。 您可以變更範圍,只收集網路控制卡叢集記錄。

  • 記錄層次。

    預設記錄層級為 [資訊]。 您可以將其變更為 [錯誤]、[警告] 或 [詳細資訊]。

  • 記錄過時時間。

    記錄會以迴圈方式儲存。 無論您使用本機記錄還是集中式記錄,預設都會有三天的記錄資料。 您可以使用 參數來變更此時間限制 LogTimeLimitInDays

  • 記錄過時大小。

    根據預設,如果使用集中式記錄,則最多會有 75 GB 的記錄資料,如果使用本機記錄,則最多會有 25 GB 的記錄資料。 您可以使用 參數來變更此限制 LogSizeLimitInMBs

收集記錄和追蹤

根據預設,VMM 部署會針對網路控制卡使用集中式記錄。 部署網路控制卡服務範本時,會指定這些記錄的檔案共用位置。

如果未指定檔案位置,則會在每個網路控制站節點上使用本機記錄,並將記錄儲存在 C:\Windows\tracing\SDNDiagnostics 底下。 這些記錄會使用下列階層來儲存:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • 追蹤

網路控制卡使用 (Azure) Service Fabric。 針對某些問題進行疑難解答時,可能需要 Service Fabric 記錄。 您可以在 C:\ProgramData\Microsoft\Service Fabric 的每個網络控制站節點上找到這些記錄。

如果使用者已執行 Debug-NetworkController Cmdlet,則每個 Hyper-V 主機上會有更多記錄可供使用,該主機已在網路控制站中使用伺服器資源指定。 這些記錄(如果已啟用則追蹤)會保留在 C:\NCDiagnostics 之下

SLB 診斷

SLBM 網狀架構錯誤 (裝載服務提供者動作)

  1. 檢查軟體負載平衡器管理員 (SLBM) 是否正常運作,以及協調流程層是否可以彼此通訊:SLBM -> SLB Mux 和 SLBM -> SLB 主機代理程式。 從任何可存取網路控制卡 REST 端點的節點執行 DumpSlbRestState
  2. 在其中一個網路控制站節點 VM 上驗證 PerfMon 中的 SDNSLBMPerfCounters(最好是主要網路控制站節點 - ): Get-NetworkControllerReplica
    1. 負載平衡器 (LB) 引擎是否連線到 SLBM? (SLBM LBEngine 組態總計 > 0)
    2. SLBM 是否至少知道自己的端點? (VIP 端點總計>= 2)
    3. Hyper-V (DIP) 主機是否連線到 SLBM? (HP 用戶端已連線 == num 伺服器)
    4. SLBM 是否連線到 Muxes? (Muxes Connected == Muxes 在 SLBM 上狀況良好 == Muxes 報告狀況良好 = #SLB Muxes VM)。
  3. 確定設定的 BGP 路由器已成功與 SLB MUX 對等互連。
    1. 如果使用 RRAS 搭配遠端存取 (也就是 BGP 虛擬機器):
      1. Get-BgpPeer 應該會顯示已連線。
      2. Get-BgpRouteInformation 應該至少顯示 SLBM 自我 VIP 的路由。
    2. 如果使用實體機架頂端 (ToR) 交換器作為 BGP 對等互連,請參閱您的檔:
      1. 例如:# show bgp instance
  4. 在 SLB Mux VM 上的 PerfMon 中驗證 SlbMuxPerfCounters 和 SLBMUX 計數器。
  5. 檢查軟體 Load Balancer Manager 資源中的設定狀態和 VIP 範圍。
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (檢查 IP 集區中的 VIP 範圍,並確保 SLBM 自我 VIP (LoadBalanacerManagerIPAddress) 和任何租使用者面向的 VIP 都在這些範圍內)
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

如果上述任何檢查失敗,租用戶 SLB 狀態也會處於失敗模式。

補救

根據顯示的下列診斷資訊,修正下列事項:

  • 確定 SLB 多工器已連線
    • 修正憑證問題
    • 修正網路連線問題
  • 確定已成功設定 BGP 對等互連資訊
  • 確定登錄中的主機識別碼符合伺服器資源 (HostNotConnected 錯誤碼的參考附錄) 中的伺服器執行個體識別碼
  • 收集記錄

SLBM 租使用者錯誤 (裝載服務提供者和租用戶動作)

  1. [Hoster]檢查 Debug-NetworkControllerConfigurationState 是否有任何 LoadBalancer 資源處於錯誤狀態。 請嘗試遵循附錄中的 [動作項目資料表] 來減輕風險。
    1. 檢查VIP端點是否存在,並公告路由。
    2. 檢查已針對VIP端點探索到多少 DIP 端點。
  2. [租使用者]驗證負載平衡器資源已正確指定。
    1. 驗證在 SLBM 中註冊的 DIP 端點是裝載租使用者虛擬機,其對應至 LoadBalancer 後端位址池 IP 組態。
  3. [主機服務提供者] 如果未探索或連線 DIP 端點:
    1. 檢查 Debug-NetworkControllerConfigurationState

      使用驗證 NC 和 SLB 主機代理程式是否成功連線到網路控制站事件協調器 netstat -anp tcp |findstr 6640)

    2. HostIdnchostagent 服務 regkey(附錄中的參考 HostNotConnected 錯誤碼)符合對應的伺服器資源的實例識別碼 (Get-NCServer |convertto-json -depth 8)。

    3. 檢查虛擬機器埠的埠配置檔標識碼是否符合對應的虛擬機 NIC 資源的實例識別碼。

  4. [裝載提供者]收集記錄。

SLB Mux 追蹤

您也可以透過事件檢視器來判斷來自軟體負載平衡器 Muxes 的資訊。

  1. 選取 [事件檢視器 檢視] 功能表下的 [顯示分析和偵錯記錄]。
  2. 在 事件檢視器 中流覽至 Windows SlbMuxDriver>追蹤Microsoft>>應用程式和服務記錄。>
  3. 以滑鼠右鍵按兩下它,然後選取 [ 啟用記錄]。

注意

建議您在嘗試重現問題時,只啟用此記錄一小段時間。

VFP 和 vSwitch 追蹤

您可以從裝載連結至租用戶虛擬網路客體 VM 的任何 Hyper-V 主機收集 VFP 追蹤,以判斷問題可能的所在位置。

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes